7.06. Docker Swarm и Kubernetes

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Архитектору Инженеру

Docker Swarm и Kubernetes

Кластеризация

Мы разобрались, как работает контейнеризация. Но как быть, если контейнеров много, и речь идёт о масштабировании и обеспечении отказоустойчивости? Давайте разберём, что такое кластеризация, и как работают такие инструменты, как Docker Swarm и Kubernetes.

★ Кластеризация — это объединение нескольких серверов (или узлов) в единую систему для выполнения общей задачи. В контексте Docker кластеризация используется для следующих целей:

Масштабирование - распределение нагрузки между несколькими узлами;
Отказоустойчивость - если один узел выходит из строя, другие продолжают работу;
Управление ресурсами - эффективное распределение ресурсов между контейнерами;
Автоматизация - автоматическое развёртывание, мониторинг и восстановление контейнеров.

Кластеризация особенно важна, если контейнеров много, приложение должно быть доступно 24/7, и нужно масштабировать приложение в зависимости от нагрузки.

Кластеризация становится необходимой в следующих случаях:

высокая нагрузка - если одно устройство не справляется с нагрузкой, нужно распределить её между несколькими серверами;
отказоустойчивость - если один сервер выходит из строя, другие продолжают работу, минимизируя простои;
географическое распределение - приложение обслуживает пользователей из разных регионов, и нужно разместить серверы ближе к пользователям;
автоматизация - если нужно автоматически разворачивать, масштабировать и мониторить контейнеры;
разделение ответственности - разные контейнеры могут работать на разных узлах, чтобы изолировать друг от друга.

Как работает кластеризация?

В кластере несколько серверов (узлов) объединяются в единую систему. Один из узлов обычно является менеджером (manager), который управляет остальными узлами (воркерами, workers). Менеджер отвечает за распределение контейнеров по узлам, мониторинг состояния узлов и восстановление контейнеров в случае сбоя.

Пример работы:

у нас есть веб-сервер и много физических серверов;
мы разворачиваем кластеризацию между физическими серверами - теперь это узлы;
мы запускаем приложение (наш веб-сервер);
менеджер определяет, на каком узле запустить контейнер;
если нагрузка увеличивается, менеджер автоматически добавляет новые экземпляры контейнера на другие узлы;
если один узел выходит из строя, менеджер переносит контейнеры на другие узлы.

Но опять же - не всё так просто.

Наше приложение, раз уж потребовалось масштабирование — это совокупность разного функционала. В приложении есть много аспектов - базы данных, кэширование, авторизация, каталог, сервисы, и многое другое. Мы уже затронули тему микросервисов ранее. Кластеризация касается именно этой темы.

Когда вы запускаете контейнер с базой данных (например, PostgreSQL), данные внутри контейнера хранятся в файловой системе контейнера. Однако, если контейнер удаляется или пересоздаётся, данные теряются. Чтобы избежать этого, используются тома (volumes).

Тома — это специальные директории на хостовой системе, которые монтируются в контейнер. Данные сохраняются вне контейнера. Пример:

docker run -d \
  --name postgres \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -v /data/postgres:/var/lib/postgresql/data \
  postgres

Здесь /data/postgres — путь на хостовой системе, где будут храниться данные PostgreSQL. Если вы добавляете новый узел в кластер, данные остаются доступными через тома, независимо от того, на каком узле запущен контейнер.

Для отказоустойчивости и масштабирования базы данных используются реплики:

Master-Slave : Один главный сервер (master) обрабатывает записи, а вторичные (slaves) — только чтение.
Распределенные базы данных : Например, PostgreSQL с шардированием или MongoDB с репликами.

Системы кэширования, например, Redis, хранят данные в оперативной памяти. При этом данные можно сохранять на диск для восстановления после перезапуска.

В кластере это работает так:

одиночный Redis - может быть запущен в одном контейнере, но это будет узким местом при высокой нагрузке;
Redis Cluster - данные распределяются между несколькими узлами (шардирование). Каждый узел хранит часть данных.

Пример:

docker run -d \
  --name redis \
  -v /data/redis:/data \
  redis redis-server --cluster-enabled yes

Если один узел выходит из строя, другие продолжают работу, обеспечивая отказоустойчивость.

Касательно веб-приложений и микросервисной архитектуры, здесь стоит отметить следующее.

Микросервисная архитектура позволяет разделить приложение на независимые модули, которые могут быть запущены в отдельных контейнерах. Это упрощает масштабирование и управление.

Предположим, у нас есть веб-приложение, которое состоит из следующих компонентов:

Авторизация: Микросервис для управления пользователями и аутентификацией.
Каталог: Микросервис для управления товарами.
Заказы: Микросервис для обработки заказов.
Фронтенд: Контейнер с веб-интерфейсом.
База данных: PostgreSQL.
Кэширование: Redis.

В кластере это будет работать так:

Авторизация и каталог могут быть размещены на одном физическом сервере.
База данных и кэширование — на другом.
Фронтенд и сервис заказов — на третьем.

Между собой микросервисы взаимоодействуют через API или сообщения (например, HTTP или gRPC). Для координации используются:

Load Balancer : Распределяет запросы между экземплярами микросервисов.
Service Discovery : Позволяет микросервисам находить друг друга (например, через DNS или Kubernetes).

Горизонтальное масштабирование. Если нагрузка на микросервис увеличивается, можно запустить дополнительные экземпляры контейнера.

Например:

docker service scale catalog-service=3

Это создаст три экземпляра микросервиса «каталог».

Балансировка нагрузки. Load Balancer распределяет запросы между экземплярами микросервиса. Например:

Nginx или Traefik могут использоваться для балансировки HTTP-запросов.
Kubernetes автоматически управляет балансировкой через Service.

Отказоустойчивость. Если один экземпляр микросервиса выходит из строя, Load Balancer перенаправляет запросы на другие экземпляры. Временные данные и сессии. Существуют и проблемы, например, проблема сессий. Если пользователь авторизован на одном экземпляре микросервиса, а его запрос перенаправляется на другой, сессия может быть потеряна. Решение - хранение сессий в Redis, чтобы они стали доступны всем экземплярам микросервиса. Пример:

docker run -d \
  --name session-store \
  -v /data/redis:/data \
  redis

Когда контейнеров становится много, требуется их оркестрация (своего рода дирижирование оркестром), то есть управление. Оркестраторы – это как раз те самые «дирижёры». Сейчас распространены Docker Swarm, Kubernetes и OpenShift.

Docker Swarm

★ Docker Swarm — это встроенная система оркестрации Docker, которая позволяет создавать и управлять кластерами контейнеров. Она проста в использовании и интегрирована с Docker Engine.

Основные компоненты как раз - менеджеры и воркеры. Менеджеры управляют кластером и отвечают за распределение задач и мониторинг, а воркеры выполняют задачи (запускают контейнеры).

Инициализация кластера:

docker swarm init

Эта команда превращает текущий узел в менеджер. 2. Добавление воркеров:

docker swarm join --token <token> <manager-ip>:<port>

Запуск сервиса:

docker service create --name my-service nginx

Масштабирование:

docker service scale my-service=3

Kubernetes

★ Kubernetes (k8s) - мощная платформа для оркестрации контейнеров, созданная Google и сейчас поддерживаемая сообществом CNCF. Kubernetes сложнее Docker Swarm, но предлагает больше возможностей.

Официальный сайт - https://kubernetes.io/

Чит-лист - https://cheatsheets.zip/kubernetes

Kubernetes (K8s) – фреймворк для гибкой работы распределенных систем для масштабирования и обработки ошибок, предоставляя:

мониторинг сервисов, балансировку нагрузки и распределение сетевого трафика;
оркестрацию хранилища – автоматическое подключение дискового хранилища к контейнерам;
автоматическое развертывание и откаты (можно автоматизировать для развертывания, удаления, распределения ресурсов в новый контейнер);
самоконтроль – автоматический перезапуск отказавших контейнеров, замена и завершение работы;
управление конфиденциальной информацией и конфигурацией (пароли, токены, ключи).

Основные компоненты:

Control Plane (плоскость управления) - управляет кластером, состоит из компонентов, таких как API Server, Sheduler, Controller Manager;
Nodes (узлы) - физические или виртуальные машины, где запускаются контейнеры;
Pods (поды) - наименьшая единица в Kubernetes. Под может содержать один или несколько контейнеров.

Контейнер собирается в под, поды собираются в рабочие узлы (ноды), ноды – это рабочие машины, которые, в свою очередь, собираются в кластер.

Кластер > Узел (нод) > Под (содержит контейнер)

Кластер – единая логическая система, состоящая из:

узлов (нод, node) – физических или виртуальных машин, на которых развернуты контейнеры, узлы включают:
- Kubelet (агент, выполняющий команды дирижёра);
- Kube-proxy (обеспечивающий сетевую связность);
- Container Runtime (среду для запуска контейнеров).
панели управления (control plane) – «дирижёр» кластера, управляющий нодами, включает:
- API Server (kubectl, входная точка для команд),
- Scheduler (планировщик, определяющий, на каком ноде запустить под),
- Controller Manager (следит за состоянием кластера),
- etcd – база данных конфигураций кластера.

Docker Desktop включает в себя встроенный Kubernetes.

На персональном ПК устанавливается одноузловый кластер Minikube.

★ Как работать с Kubernetes:

подготовка – развернуть кластер, указав количество control plane и worker node, в отличие от Docker – здесь кластер, а не машина;
разработка приложения;
определение сервисов, подов, конфигурации, масштабирования;
формирование манифестов (вместо Dockerfile используется YAML-манифест);
сборка образа (docker build);
публикация образа (docker push) в репозиторий;
деплой – вместо docker run будет kubectl apply -f deployment.yaml – применение манифеста к кластеру, Kubernetes сам скачает образ, создаст поды согласно replicas, настроит сеть и другие ресурсы по манифесту;
тестирование – в отличие от Docker, тестировать можно не один контейнер, а всё приложение целиком (включая все поды по списку, балансировку и сеть);
деплой на продакшн.

★ Особенности работы с Kubernetes

Действие	Kubernetes
Запуск	`kubectl apply -f deployment.yaml` Создаётся указанное в YAML-манифесте количество подов (контейнеров).
Масштабирование	Определяется в манифесте YAML. Поддерживается автоматическое масштабирование. При сбое одного пода новый создаётся автоматически.
Сеть	Глобальная маршрутизация настраивается через YAML-манифесты с использованием сетевых плагинов: • Service — абстракция для доступа к подам: – ClusterIP (внутренний IP), – NodePort (порт на каждой ноде), – LoadBalancer (облачный балансировщик). • Ingress — управление маршрутизацией HTTP/HTTPS-трафика. • CNI (Calico, Flannel) — плагины для организации сети между подами на разных нодах.
Хранение данных	Используются облачные или локальные диски, настраиваемые через YAML-манифесты: • PersistentVolume (PV) — ресурс хранилища в кластере. • PersistentVolumeClaim (PVC) — запрос на использование хранилища от имени пода. • StorageClass — шаблон для динамического выделения томов (например, в облачной среде).
Обновление приложения	Управляется через YAML-манифесты: • Rolling Update — поэтапное обновление: новые поды с новой версией запускаются, старые удаляются после успешной проверки. Обеспечивает обновление без простоя. • Blue-Green Deployment — развёртывается полная копия приложения с новой версией, после проверки трафик переключается на неё одномоментно.
Отказоустойчивость	Обеспечивается на уровне подов: при сбое под автоматически пересоздаётся.
Динамическое масштабирование	Поддерживается (на основе метрик, таких как загрузка CPU или памяти), реализуется через Horizontal Pod Autoscaler (HPA).

Первый шаг в использовании Kubernetes — это его корректная установка. Процесс начинается с подготовки окружения, установки необходимых пакетов и конфигурации узла.

Подготовка системы : Прежде всего, необходимо отключить swap-раздел, так как Kubernetes требует работы без него. Это можно сделать командой sudo swapoff -a. Чтобы изменение сохранялось после перезагрузки, следует отредактировать файл /etc/fstab.
Установка Docker : Kubernetes использует Docker (или другой runtime) для запуска контейнеров. Установка выполняется командой:

sudo apt-get update && sudo apt-get install -y docker.io

Установка kubeadm, kubelet и kubectl : Эти компоненты являются основными для работы Kubernetes. Их можно установить через официальный репозиторий Kubernetes:

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg  | sudo apt-key add -
echo "deb https://apt.kubernetes.io/  kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl

Инициализация кластера: После установки всех компонентов можно инициализировать мастер-узел командой sudo kubeadm init. Далее потребуется выполнить дополнительные действия для настройки доступа к кластеру, например, скопировать файл конфигурации в домашнюю директорию пользователя. После успешного развёртывания кластера следующий этап — описание приложения в формате YAML. Kubernetes использует декларативный подход, где все параметры указываются в манифестах. Рассмотрим пример развёртывания NGINX с тремя репликами, настройкой портов и проверками работоспособности.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "256Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

Этот манифест создаёт три реплики NGINX-подов, каждая из которых открывает порт 80. Параметры livenessProbe и readinessProbe обеспечивают проверку работоспособности и готовности подов соответственно. Если проверка не проходит, Kubernetes автоматически перезапускает контейнер. Ограничения ресурсов (resources.limits) помогают предотвратить чрезмерное использование CPU и памяти.

Для применения манифеста используется команда kubectl apply -f deployment.yaml. При необходимости масштабирования можно использовать команду kubectl scale deployment.v1.apps/nginx-deployment --replicas=5, чтобы увеличить число реплик до 5.

Мониторинг кластера является важнейшим аспектом управления Kubernetes.

Команда kubectl cluster-info : Эта команда выводит базовые сведения о компонентах кластера, таких как адрес API-сервера и статус etcd.

Например, выполнение команды может дать следующий результат:

Kubernetes control plane is running at https://192.168.99.100:8443
CoreDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Команда kubectl get nodes : Она показывает список всех узлов кластера и их статус. Например:

NAME       STATUS   ROLES                  AGE   VERSION
node1      Ready    control-plane,master   2d    v1.23.4
node2      Ready    <none>                 2d    v1.23.4
node3      Ready    <none>                 2d    v1.23.4

Если какой-либо узел находится в состоянии NotReady, это может свидетельствовать о проблемах с сетью, недоступностью ресурсов или ошибками в конфигурации. Для более глубокого анализа можно использовать команду kubectl describe node <node-name>.

Таким образом, Kubernetes предоставляет комплексный набор инструментов для развёртывания и управления приложениями, начиная от базовой установки и заканчивая мониторингом и отладкой.

Инструменты и компоненты Kubernetes

Основные компоненты Kubernetes

Контрольная плоскость (Control Plane)

kube-apiserver : API-сервер для управления кластером.
etcd : Распределённое хранилище данных кластера.
kube-scheduler : Планировщик подов на узлы.
kube-controller-manager : Управление контроллерами (например, ReplicaSet, Deployment).
cloud-controller-manager : Интеграция с облачными провайдерами.

Узловые компоненты (Node Components)

kubelet : Агент, который управляет подами на узле.
kube-proxy : Прокси для сетевого трафика между подами.
Container Runtime : Среда выполнения контейнеров (например, containerd, CRI-O).

Управление ресурсами

Развертывание и масштабирование

Deployment : Управление состоянием приложений.
StatefulSet : Для приложений с состоянием (например, базы данных).
DaemonSet : Запуск пода на каждом узле (например, для мониторинга).
Job/CronJob : Выполнение одноразовых или периодических задач.
HPA (Horizontal Pod Autoscaler) : Горизонтальное масштабирование подов.
VPA (Vertical Pod Autoscaler) : Вертикальное масштабирование (увеличение ресурсов).
KEDA (Kubernetes Event-driven Autoscaling) : Масштабирование на основе событий.

Хранилище

PersistentVolume (PV) : Объём постоянного хранилища.
PersistentVolumeClaim (PVC) : Запрос на использование хранилища.
StorageClass : Классы хранилищ для динамического provisioner'а.
CSI (Container Storage Interface) : Интерфейс для интеграции хранилищ.
Longhorn : Распределённое блочное хранилище для Kubernetes.
Rook : Оркестрация распределённых хранилищ (например, Ceph).

Сети и DNS

Сетевые компоненты

CNI (Container Network Interface) : Интерфейс для сетевых плагинов.
- Calico : Сетевой плагин с поддержкой сетевой политики.
- Flannel : Простой сетевой плагин.
- Weave Net : Сетевой плагин с шифрованием.
Ingress : Управление входящим трафиком.
- NGINX Ingress Controller .
- Traefik : Альтернатива NGINX.
- HAProxy Ingress : Высокопроизводительный контроллер.
Service Mesh :
- Istio : Service Mesh для микросервисов.
- Linkerd : Лёгкий Service Mesh.
NodeLocal DNS Cache : Локальный DNS-кэш для узлов.

Безопасность сети

NetworkPolicy : Ограничение трафика между подами.
CoreDNS : DNS-сервер для Kubernetes.
ExternalDNS : Синхронизация DNS-записей с сервисами.

Безопасность

Управление секретами

Secrets : Хранение чувствительных данных.
ConfigMaps : Хранение конфигураций.
HashiCorp Vault : Централизованное управление секретами.
External Secrets Operator : Синхронизация секретов с внешними хранилищами.

Политики безопасности

Pod Security Policies (PSP) : Устаревший механизм для ограничений.
Kyverno : Политики безопасности для Kubernetes.
Open Policy Agent (OPA) : Фреймворк для политик (например, Gatekeeper).

RBAC

Role/ClusterRole : Определение прав доступа.
RoleBinding/ClusterRoleBinding : Привязка ролей к пользователям или группам.

Мониторинг и логирование

Мониторинг

Prometheus : Сбор метрик.
Grafana : Визуализация метрик.
Metrics Server : Сбор метрик для HPA.
Kubernetes Event Exporter : Экспорт событий Kubernetes.
Loki : Система сбора и анализа логов.
Tempo : Система распределённой трассировки.

Логирование

EFK Stack (Elasticsearch, Fluentd, Kibana) : Сбор и анализ логов.
Fluent Bit : Лёгкий агент для сбора логов.

Управление кластером

Оптимизация и балансировка

Descheduler : Перераспределение подов для оптимизации ресурсов.
Cluster Autoscaler : Автоматическое масштабирование узлов.
Node Affinity/Anti-Affinity : Управление размещением подов.

Облачные провайдеры

AWS EKS : Управляемый Kubernetes в AWS.
Google GKE : Управляемый Kubernetes в Google Cloud.
Azure AKS : Управляемый Kubernetes в Azure.
OpenShift : Платформа на базе Kubernetes от Red Hat.

CI/CD

ArgoCD : GitOps-инструмент для развертывания приложений.
Tekton : Фреймворк для CI/CD.
Jenkins X : CI/CD для Kubernetes.

Custom Resource Definitions (CRD)

CRD и операторы

Custom Resource Definition (CRD) : Расширение Kubernetes для пользовательских ресурсов.
Operator Framework : Разработка операторов для автоматизации.
Prometheus Operator : Управление Prometheus через CRD.
Cert-manager : Автоматизация управления сертификатами TLS.
Istio Operator : Управление Istio через CRD.

Дополнительные инструменты

Управление конфигурацией

Helm : Менеджер пакетов для Kubernetes.
Kustomize : Инструмент для настройки манифестов.

Тестирование

kubectl : Командная строка для взаимодействия с кластером.
kubebuilder : Фреймворк для создания операторов.
Sonobuoy : Инструмент для тестирования кластера.

Анализ производительности

Sysdig : Мониторинг и безопасность.
Datadog : Мониторинг и аналитика.

Бэкапы

Velero : Инструмент для резервного копирования кластера.
WAL-G : Инструмент для бэкапов баз данных.

Хранилище

Restic : Инструмент для резервного копирования данных.
MinIO : Объектное хранилище, совместимое с S3.

Диагностика

Lens : Графический интерфейс для Kubernetes.
Octant : Инструмент для анализа кластера.

Расширенные инструменты

Мультикластерное управление

Rancher : Управление несколькими кластерами.
Deckhouse : Платформа для управления Kubernetes.

Инструменты для разработчиков

Minikube : Локальный кластер для разработки.
Kind (Kubernetes IN Docker) : Локальный кластер в Docker.
Skaffold : Инструмент для разработки приложений в Kubernetes.

Сервисы и интеграции

Service Catalog : Интеграция с внешними сервисами.
Knative : Платформа для serverless-приложений.

Helm — это менеджер пакетов для Kubernetes. Он упрощает развертывание и управление приложениями в Kubernetes-кластере с помощью шаблонов (чартов).

Helm-чарт — это пакет, который содержит все необходимые файлы для развертывания приложения в Kubernetes. Чарт включает:

templates/ - шаблоны манифестов Kubernetes (deployment, service, configmap и т.д.).
values.yaml - файл с переменными, которые могут быть переопределены при установке.
Chart.yaml - метаданные о чарте (название, версия, описание).
charts/ - зависимости от других чартов.

Helm используется для автоматизации развертывания приложений в Kubernetes. Вместо ручного создания YAML-файлов Helm позволяет использовать параметризованные шаблоны, управлять ависимостями между компонентами приложения, а также обновлять и откатывать версии приложений.

Как работает Helm:

Пользователь создает или загружает Helm-чарт.
Helm компилирует шаблоны в YAML-файлы Kubernetes.
Эти файлы применяются к кластеру через kubectl.

OpenShift — это платформа контейнеризации, основанная на Kubernetes. Она предоставляет дополнительные функции для корпоративных пользователей, такие как встроенный реестр контейнеров, графический интерфейс управления (Web Console), инструменты CI/CD, потоковая передача логов и мониторинг, а также поддержка безопасности и соответствия стандартам. В отличие от «чистого» Kubernetes, OpenShift предоставляет больше готовых решений и включает встроенные инструменты для разработчиков.

HAProxy Ingress — это контроллер входящего трафика (Ingress Controller) для Kubernetes, основанный на HAProxy. Он маршрутизирует внешний трафик к сервисам внутри кластера.

Longhorn — это распределенная система хранения данных для Kubernetes. Она предоставляет управление томами (Persistent Volumes) с поддержкой репликации, мониторинг состояния томов и автоматическое восстановление данных при сбоях.

Affinity (сродство) — это механизм в Kubernetes, который позволяет назначать поды на определенные узлы (nodes) на основе заданных условий. Например, размещение подов на узлах с определенной меткой или группировка подов вместе для улучшения производительности.

Anti-affinity (анти-сродство) — это противоположный механизм, который предотвращает размещение подов на одних и тех же узлах. Это полезно для разделение подов по разным узлам и предотвращения перегрузки одного узла.

Security Context — это механизм в Kubernetes, который позволяет задавать параметры безопасности для подов или контейнеров. Он используется для контроля прав доступа, привилегий и других аспектов безопасности.

Уровни настройки:

На уровне Pod параметры применяются ко всем контейнерам в поде.
На уровне контейнера параметры применяются только к конкретному контейнеру.

Основные параметры:

runAsUser: указывает UID пользователя, от имени которого запускается контейнер.
runAsGroup: указывает GID группы.
fsGroup: задает группу для файловой системы.
privileged: разрешает или запрещает привилегированный режим.
readOnlyRootFilesystem: делает файловую систему контейнера доступной только для чтения.
capabilities: управляет возможностями Linux (например, добавление/удаление прав).

Hostpath-provisioner — это динамический provisioner для Kubernetes, который создает Persistent Volumes (PV) на основе локальных директорий узлов (hostPath). Применяется при развёртывании в одноконтроллерных кластерах (например, Minikube).

HPA — это встроенный механизм Kubernetes для автоматического горизонтального масштабирования подов на основе метрик (например, CPU, память, пользовательские метрики). HPA мониторит метрики через Metrics Server. На основе заданных целевых значений (например, 50% CPU) увеличивает или уменьшает количество реплик пода.

KEDA (Kubernetes Event-driven Autoscaling)— это инструмент для автоматического масштабирования приложений в Kubernetes на основе событий. В отличие от Horizontal Pod Autoscaler (HPA), который масштабирует поды на основе метрик (например, CPU или памяти), KEDA использует внешние события (например, количество сообщений в очереди). KEDA работает как Custom Resource Definition (CRD) и легко интегрируется.

Descheduler — это инструмент для перераспределения подов в Kubernetes-кластере. Он помогает оптимизировать использование ресурсов и равномерно распределять нагрузку между узлами.

NodeLocal DNS Cache — это компонент Kubernetes, который улучшает производительность DNS-запросов за счет кэширования их на уровне узла.

DNAT — это метод трансляции сетевых адресов, при котором изменяется адрес назначения пакета. Это используется для маршрутизации трафика на внутренние серверы через внешний IP-адрес, к примеру назначение внешних IP-адресов для Kubernetes Services типа LoadBalancer.

CoreDNS — это гибкий DNS-сервер, используемый в Kubernetes для разрешения доменных имен внутри кластера. CoreDNS заменил kube-dns как стандартный DNS-сервер в Kubernetes.

Kubernetes Event Exporter — это инструмент для экспорта событий Kubernetes в системы логирования или мониторинга (например, Elasticsearch, Loki, Prometheus). Основные функции - сбор событий из кластера (например, создание подов, ошибки), выборка событий по типу, объекту или другим параметрам и отправка данных в различные системы.

Cert-manager — это инструмент Kubernetes для автоматического управления сертификатами TLS. Он позволяет получать, обновлять и применять сертификаты из таких источников, как Let's Encrypt.

Custom Resource Definition (CRD) — это механизм Kubernetes, который позволяет пользователям создавать собственные типы ресурсов. CRD расширяет функциональность Kubernetes, позволяя добавлять новые объекты для управления специфическими задачами.

Как работает:

Пользователь определяет новый тип ресурса через CRD.
Kubernetes API начинает поддерживать этот тип.
Пользователи могут создавать, изменять и удалять экземпляры этого ресурса.

В Kubernetes Secret — это объект, который используется для хранения чувствительных данных, таких как сертификаты, ключи и пароли. Для работы по HTTPS можно создать Secret, содержащий TLS-сертификат и приватный ключ.

Deckhouse — это платформа для управления Kubernetes-кластерами, разработанная компанией Flant. Она предоставляет инструменты для автоматизации развертывания, масштабирования и мониторинга кластеров.

PrometheusRule — это Custom Resource Definition (CRD) в Kubernetes, используемый для определения правил алертинга и записи метрик в Prometheus.

Alerting Rules : правила для генерации алертов на основе метрик. Recording Rules : правила для предварительной агрегации метрик. Интеграция с Kubernetes : управление правилами через Kubernetes API.

Docker Swarm и Kubernetes​

Кластеризация​

Docker Swarm​

Kubernetes​

Инструменты и компоненты Kubernetes​

Docker Swarm и Kubernetes

Кластеризация

Docker Swarm

Kubernetes

Инструменты и компоненты Kubernetes